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ABSTRACT 

The Data System Operations Team (DSOT) currently monitors the Multimission 
Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory. The MGDS 
currently supports five spacecraft and within the next five years it will 
support ten spacecraft simultaneously. The ground processing element of the 
MGDS consists of a distributed UNIX-based system of over 40 nodes and 100 
processes. The MGDS system provides operators with little or no information 
about the system's end-to-end processing status or end-to-end configuration. 
The lack of system visibility has become a critical issue in the daily operation 
of the MGDS. A task analysis was conducted to determine what kinds of tools 
were needed to provide DSOT with useful status information and to prioritize 
the tool development. The analysis provided the formality and structure 
needed to get the right information exchange between development and 
operations. This paper describes how even a small task analysis can improve 
developer-operator communications and examines the challenges associated 
with conducting a task analysis in a real-time mission operations 
environment. 

INTRODUCTION 

Any human factors engineer would leap at the opportunity to 
conduct a task analysis for a project. Likewise, project managers 
would appreciate any opportunity to gain insightful information 
about their customer's needs and what products will meet those 
needs. Still task analyses are not typically incorporated into the 
software development life cycle. This absence is especially odd since 
system development is a highly interactive process. 

The system development process is usually considered a logical, 
intellectual process, but it often contains many "irrational and 
nonintellective elements" (Meister, 1971). Even with a good 
understanding of task analysis methods and their proper application, 
the analysis may still be subject to other influencing factors like 
time, budget, and (most importantly) the cooperation of engineers 
(Meister, 1991). However, even a small task analysis reveals useful 
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information and insight that would otherwise go unnoticed if no 
analysis was done at all. 

THE SYSTEM 

The task analysis described in this paper was conducted to 
understand the daily activities of the Data System Operations Team 
(DSOT) who are responsible for running the Multimission Ground 
Data System (MGDS). The MGDS provides spacecraft telemetry data 
capture, data processing and display, and system monitor and control 
capabilities. Data is received into the system from the spacecraft via 
the Deep Space Network (DSN). The DSN is a network of antennas 
through which commands are sent to the spacecraft and data is 
received from the spacecraft and forwarded to the MGDS. The Data 
System Operations Team monitor the data from the DSN and follow it 
closely as it is processed through the MGDS and delivered to project 
scientists, spacecraft teams, NASA centers, principal investigators 
and other end users (Figure 1). 


MGDS 



Figure 1. MGDS Operators Keep MGDS Running So End Users May 
Receive Data and Command the Spacecraft 


DSOT primarily focuses on the MGDS itself and how it is functioning, 
as well as the packaging, routing, and storing of the data, rather than 
with actual data values and their significance (Miller et al, 1992). 
Operators rely on experience, teamwork and existing tools to monitor 
the system and get the data to the system users. 

Figure 2 shows a simplified MGDS end-to-end data flow. Running the 
front-end of the system is labor intensive and difficult. It's labor 
intensive because the setup for a DSN tracking pass-configuring the 
processing of the data through the system-is a manual process. 
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Although some of the setup activities are scripted, they are not 
automated at startup, and once running there is no mechanism for 
managing the hierarchy of activities. The process is difficult because 
there are no tools that provide data accountability or visibility into 
front-end data processing. For example, DSOT has no tool that 
estimates the amount of data (by type) a project is expecting from a 
given track for all the project's data types; nor is there a way to 
estimate what the output products should be across the front-end 
subsystems. 
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Figure 2. Simplified End-To-End MGDS Data Flow 

In order to reduce operations costs through improved efficiency in 
DSOT, an initiative called DSOT Cockpit was funded to address the 
special needs of the DSOT operators. The goal of DSOT cockpit was to 
provide much-needed visibility into the system's front-end 
processing where DSOT operations are focused. Tools that display 
information about the current and expected system status are key 
elements of the DSOT cockpit effort to improve mission operations. 
The lack of system visibility is critical to mission operations because 
when a flight project suddenly stops receiving data, DSOT must find 
the problem and solve it in real-time. The tools needed to see what 
is happening in the system did not exist. The task analysis was 
conducted to identify what tools were needed and to prioritize 
development of those tools. 

TASK ANALYSIS 

Fortunately, management had a good understanding of what a task 
analysis entailed and what to expect from it. Getting both 
development and operations management support was not as 
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difficult as originally anticipated. Before the analysis began, 
managers were briefed on the purpose of this task analysis and what 
they could realistically expect to find from it. The development side 
agreed to implement the tools according to the findings in the 
analysis. 

In the interest of time and resources, the task analysis had to be fast, 
be efficient, and produce reliable results. At a minimum, the results 
needed to recommend solutions that were as good as or better than 
those that the developers had come up with on their own. It also 
needed to accurately reflect the daily tasks of DSOT in terms 
developers could understand and recommend ways to improve DSOT 
operations. 

One particular challenge was finding a standard task analysis format 
for real-time mission operations. There isn't one. The closest thing 
to a standard is the Handbook for Designers of Instructional Systems. 
The goals of this analysis had to be considered and the methods had 
to be selected, adapted, or developed from the Handbook. At first it 
seemed overwhelming, but it quickly became clear that for any task 
analysis, there will be diverse variables that will influence the 
analysis, design, methods of data collection, and the resulting design 
recommendations. The process of selecting the task analysis 
methods and format for DSOT took longer than expected but was 
worth the effort. 

Methods 

The primary methods of data collection were individual interviews 
and observations of work activities. These methods were selected 
because they were simple, fast, and minimally disruptive during 
operations. The interviews were conducted at the individual 
operators' workstations, so the operators were not removed from 
their work areas. There was only one instance of an interview 
having to be rescheduled because of a system problem that required 
immediate attention. 

The original task analysis proposal stated that all operators would be 
interviewed, however because of resource constraints only a random 
sample of the team could be interviewed. The sample was selected 
by randomly selecting names from a list of operators. A total of 10 
operators were interviewed. 
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Approximately 20 operators were observed and some of the 
interviewees were included in the group that was observed. 

All the interviews followed a questionnaire of 20 questions regarding 
DSOT's activities, common problems, frustrations, ways to improve 
the system and demographics. The last part of the interview was 
reserved for the operator's questions about the questions or to 
provide additional information that was not covered. The interviews 
went smoothly but sometimes turned into gripe sessions about 
management, the system, or the organization. Some of the operators 
expressed frustration with their lack of representation in 
development and design decisions that affect how their tasks are 
performed or cause changes to the tasks themselves. Comments 
about the organization, system, or management were noted and 
forwarded to the appropriate persons, but were not presented in the 
final findings of the task analysis. At times it was a challenge to 
keep the interview focused on DSOT tasks as opposed to complaints. 
Most of the information offered by the operators at the end of the 
interviews was insightful and honest information that would not 
have been communicated if the task analysis was not conducted. 

Another common problem encountered during the interviews was 
short answers. Many of the operators had not put much thought into 
ways to improve the system, but rather had concentrated on making 
the system work in the current environment. This finding was a 
surprise because we assumed that the operators would have a lot of 
immediate suggestions. 

The interview method provided good information, but only what 
little information was offered by (or drawn out of) the operators. 

The observations were intended to fill this gap, but running the 
MGDS is complex and simply observing an operator was not as 
informative as expected. As a result, the oberservation sessions 
provided little useful information. 

The notes from the interviews and the observation sessions were 
sorted into a table (similar to Table I) and categorized by task type, 
difficulty of implementation, and criticality to improving operations 
efficiency. Each task was categorized into 3 groups (Cushman and 
Rosenberg, 1991): 

S Sequential: There is a prescribed order in which task 
elements and sub tasks must be accomplished. 
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B Branching: Subsequent task options are based on 
previous task choices. 


P Process: Continuous monitoring of a process where the 

user initiates control movements based on feedback from 
the system. 

Table I. Task Categories and Ratings (Example) 
Task/Problem Task Tvoe ImDortance Difficulty 

Data gap 
detection 

B 

4 

3 

End-to-end 

system 

configuration 

information 

P 

5 

5 

Post-pass data 
analysis tool 

S 

3 

2 

Show data loss 
between GIF 
and TIS 

P 

5 

3 


Most of the tasks DSOT conducts are process oriented, making them 
difficult to analyze. The importance rating was given on a scale of 1- 
5 with 5 being the most important. The rating was based on the data 
received from the interviews. Some of the importance ratings were 
subjective, while others were definitive. The difficulty rating was 
given on the same 1-5 scale as the importance rating; it was based on 
developers estimates. Surprisingly, the rated importance of a task or 
problem varied considerably between operators. This variance was 
attributed to differences in problem-solving styles and experience. 

Another surprise was the general displeasure the operators 
expressed with the usability and stability of the system. Even when 
specific problems were not identified, each operator said the system 
was difficult to learn, use, and operate. 

CONCLUSION 

This task analysis brought new insight and understanding about 
operations teams and how individuals use the delivered tools, or 
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adjust to the lack of tools, to run the system. The analysis facilitated 
constructive communication between development and operations 
while the analysis was being conducted and has since resulted in 
more open communications. 

The following task analysis tips are based on this experience. They 
are basic, but they are essential to the use of task analysis as a tool 
for meeting development and operations goals: 

• Define the purpose of the analysis. Task analyses have a variety of 
purposes; be sure to clearly state which purpose the analysis is 
aiming to accomplish. 

• Be flexible to changes in budget, personnel, or analysis methods. 
Adaptability is critical to the success of the analysis in a mission 
operations environment that changes. 

• At a minimum, get one person on the development side and one on 
the operations side to be champions for the analysis. An 
endorsement will make the analysis run more smoothly and the 
results will have a better chance of getting implemented. 

• Keep everyone informed of the analysis progress or lack of 
progress. Continuous flow of status information is key to continued 
support. 

Remember, even the simplest analysis can bring more benefit than 
no analysis brings. It will find hidden problems, highlight strengths, 
and confirm understandings. It is the key element to making 
products and systems usable. Task analysis must be included in the 
development lifecycle (on any scale) in order to develop efficient, 
usable systems. If you have any doubts, give it a try. 
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